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ABSTRACT 

Building complex software systems necessitates the use of 
component-based architectures. In theory, of the set of com- 
ponents needed for a design, only some small portion of 
them are "custom"; the rest are reused or refactored existing 
pieces of software. Unfortunately, this is an idealized situ- 
ation. Just because two components should work together 
does not mean that they will work together. 

The "glue" that holds components together is not just tech- 
nology. The contracts that bind complex systems together 
implicitly define more than their explicit type. These "con- 
ceptual contracts" describe essential aspects of extra-system 
semantics: e.g., object models, type systems, data represen- 
tation, interface action semantics, legal and contractual obli- 
gations, and more. 

Designers and developers spend inordinate amounts of time 
technologically duct-taping systems to fulfill these concep- 
tual contracts because system-wide semantics have not been 
rigorously characterized or codified. This paper describes a 
formal characterization of the problem and discusses an ini- 
tial implementation of the resulting theoretical system. 

Categories and Subject Descriptors 

D.1.0 [Software]: Programming Techniques — General; D.2 
[Software]: Software Engineering; D.3.1 [Software]: Pro- 
gramming Languages — Formal Definitions and Theory; D.3.4 
[Software]: Programming Languages — Processors [prepro- 
cessors]; F. 3.1 [Theory of Computation] : Logics and Mean- 
ings of Programs — Specifying and Verifying and Reasoning 
about Programs; FA.l [Theory of Computation] : Mathe- 
matical Logic and Formal Languages — Mathematical Logic; 
F.4.3 [Theory of Computation]: Mathematical Logic and 
Formal Languages — Formal Languages 



General Terms 

specification languages, formal methods, kind theory, reuse, 
glue-code generation, automatic programming, domain-specifi 
languages 

1. INTRODUCTION 

Modern software systems are increasingly complicated. Com- 
bine new technologies, complex architectures, and incredi- 
ble amounts of legacy code, and you have systems that no 
one can even partially comprehend. As complexity rises, 
code quality drops and system reliability suffers. 

Building reliable complex systems necessitates the use of 
excellent software engineering practices and tools. But even 
with this bag of tricks, the modern software engineer is of- 
ten overwhelmed with the technological problems inherent 
in building such complex systems. Most projects have to 
support multiple programming languages and models, deal 
with several different architectures (both hardware and soft- 
ware), have distributed and concurrent subsystems, and must 
be faster, cheaper, and better than their competitors. 

What is worse, while these technological challenges are daunt- 
ing, it is the non-technological issues that are often insur- 
mountable. The widespread lack of system, design, and 
component documentation, ignorance about testing and qual- 
ity assurance, and lack of communication/knowledge across 
teams/companies, make for a very difficult working envi- 
ronment. The situation is further compounded by the so- 
cial problems rampant in information technology: the Not- 
Invented-Here syndrome; issues of trust among companies, 
teams, and developers; developer education and motivation; 
and managerial and business pressures. 

1.1 Semantic Components with 
Conceptual Contracts 

Since developers of reusable constructs (like chunks of code 
or paragraphs of documentation) can not say what they mean, 
there is a "meaning-mismatch". This "information-impedance' 
muddles communication between collaborators as well as 
complicates composition between components. 



GCSE/SA1G '02 2002 Pittsburgh, PA, USA 



A new semantic theory, specifically designed to address this 
and related problems, can help solve this "meaning-mismatch" 
If is our belief that if such a product were widely available 



and integrated into all aspects of system development, then 
our systems would be easier to build, better documented, and 
more robust. Put more plainly, our systems would be more 
correct. 

This paper aims to (1) provide a means by which compo- 
nents can be semantically (conceptually, formally) described, 
(2) present an algorithm which automatically determines when 
components can inter-operate regardless of syntax or com- 
ponent model, and (3) describe the means by which the adapters 
necessary to compose such components can be automatically 
generated. 

A component that is specified, manipulated, and reasoned 
about using this (or functionally similar) theory, tools, and 
techniques is what we call a semantic component. 

The theoretical foundation for this work is a new logic for 
describing open collaborative reusable assets called kind the- 
ory, which is described in full in Kiniry's Ph.D. disserta- 
tion | O) . 

1.2 Related Work 

Various pieces of research from several communities has 
similarities to this work. At its most simple, straightforward 
structural subtyping can be used as a theoretical framework 
for semantic composition, especially in strongly typed lan- 
guages; e.g., Muckelbauer's work in distributed object-based 
systems |20|. The problem with this approach is that only 
renaming and reordering operations are possible, and little 
theoretical infrastructure supports reasoning about the full 
semantics of components. 

Stronger theoretical formalisms exists for specifying and rea- 
soning about such compositional systems; for example, the 
recent work of Molina-Bravo and Pimentel 1 19 1. But such 
work is far from being practically applicable in the near fu- 
ture as there is no strong connection with real programming 
languages, software engineering methods, and no tool sup- 
port. 

Other expressive formalisms for compositionality exist, pri- 
marily in the category theoretic domain |9|. This work is 
starting to see real application as Fiadeiro has moved into a 
more industrial role in promoting this technology. 

Work at CMU by Yellin and Strom, inspired by the prob- 
lems with the Aesop system 1 1 1 1, has covered this territory 
before in the context of object protocols and weak, non- 
formal semi-automatic adapter construction 1271 1281 . The 
work has a very ad hoc feel, even after the development of 
a formal model for such architectures 1 2 1. We plan on using 
this model as a motivating example for the evolution of our 
own design language, Extended BON 1 14 1. 

In a Java context, Wang et al proposed an service-event model 
with an ontology of ports and links, extending the JavaBeans 
descriptor model 1 26) . 

Other related work comes from the areas of: domain-specific 



languages, especially for component specification and re- 
use 1 23 1; the automatic programming community, e.g, early 
work by Barstow 1 3 , 4 1 and Cleveland 1 7 1 ; conceptual reuse 
such as Castano and De Antonellis |5 1; and last but certainly 
not least, the software transformation systems community, 
including the voluminous works of Biggerstaff and Batory. 

Much of this work is reviewed nicely in I8l l22ll24l . 

The primary difference between all of these formalisms and 
systems and ours is that our system has a broad, firm theo- 
retic foundation. That foundation, kind theory, was specif- 
ically designed to reason about reusable assets in an open 
collaborative context. Thus, our work is not tied to a spe- 
cific language or realization, integrates the domains of reuse, 
knowledge representation, automatic programming, and pro- 
gram transformation, and does so in a theoretical and sys- 
tematic framework that supports global collaboration among 
many participants. 

2. SEMANTIC COMPOSITION 

Our proposal is, on the surface, relatively simple. Instead of 
having only a syntactic interface to a component, we provide 
a higher-level semantic specification. Additionally, provid- 
ing this semantic specification does not entail the need for 
a developer to learn any new heavyweight specification lan- 
guage, theory, or tools. 

The key to this new solution is the notion of semantic com- 
patibility 1 16 1 . Components are described explicitly and im- 
plicitly with lightweight, inline, domain-specific documen- 
tation extensions called semantic properties. These proper- 
ties have a formal semantics that are specified in kind theory 
and are realized in specific programming languages and sys- 
tems. 

When used in tandem with a computational realization of 
kind theory (called a kind system), these semantic compo- 
nents are composed automatically through the generation of 
"glue" code, and such compositions are formally validated. 

3. A BRIEF OVERVIEW OF 
KIND THEORY 

Kind are classifiers used to describe reusable assets like pro- 
gram code, components, documentation, specifications, etc. 
Instances are realizations of kind — actual embodiments of 
these classifiers. For example, the paperback "The Portrait 
of the Artist as a Young Man" by James Joyce is an instance 
of kinds PaperbackBook and EnglishDocument, (and 
perhaps others). We write this as 



Portrait : PaperbackBook © EnglishDocument 

We use kind theory to specify semantic properties because 
it provides us with an excellent model-independent (i.e., it 
is not bound to some specific programming language) reuse- 
centric formalism. 



3.1 Structure 

Kinds are described structurally using our logic in a number 
of ways using several core operators. Classification is cov- 
ered with the inheritance operators < and < p ; structural re- 
lationships are formalized using the inclusion operators C p 
and D, equivalence has several forms, = and <; realization, 
the relationship between instances and kind, is formalized 
with the operators < r and :; composition is captured in sev- 
eral forms, ®, ©, and o; and interpretation, the translation 
of kind to kind or instances to instances, is realized with the 
operators and 

3.2 Operators 

3.2.1 Inheritance 

Inheritance is a relation that holds between a child kind and 
one or more parent kinds. The generic notion of inheritance 
is that some qualities are transferred by some means from 
parent to child. Inheritance is the relation that is used pri- 
marily to classify kind. 

The basic symbols that we use for inheritance are < p , <, 
and < r to connote order on kind. Inheritance is a reflexive, 
transitive, asymmetric operation. 

Inheritance in the form of classification is one of the most 
common structuring notions known in science. Variants of 
Aristotle's genera and species and the Linnaean method has 
been used in various incarnations for hundreds of years to 
classify organisms and entities. Another example of inher- 
itance comes from library science where researchers have 
developed several classification schemas for books: e.g., the 
Library of Congress and the Dewey Decimal Systems. 

Some forms of subtyping and inheritance in modern for- 
malisms and programming languages are sometimes also kinds 
of inheritance (they are not when they have nothing to do 
with semantic conformance). 

3.2.2 Inclusion 

Inclusion is a relation that holds between two constructs, the 
whole and the part. A part is a portion of the whole. We 
use the term has-a to connote inclusion. The basic symbols 
that we use for inclusion are C p and D to connote structural 
containment. 

Consider this document. We can hierarchically decompose 
its entire physical structure in a variety of different ways. For 
example, syntactically, letters make up words, words make 
up sentences, sentences make up paragraphs, etc. Thus, para- 
graphs have sentences and, specifically, a given paragraph 
has-a particular sentence. 

Inclusion is also a reflexive, transitive, asymmetric opera- 
tion. 

3.2.3 Equivalence 

Equivalence is a relation that holds between constructs that 
are the "same" in some context. Two constructs are equiv- 
alent if they are similar for one or more reasons. The basic 



symbols that we use for equivalence are = and =, and the 
related <. 

Equivalence is a context-sensitive relation. Consider the two 
strings "Y = 2 * X" and "Z = X * 2". Textually, they are 
not equivalent because they contain different characters. If 
interpreted in an algebraic setting, they are potentially equiv- 
alent equations, but it depends upon the specific algebras in 
question. If they both are interpreted in the same algebra, 
if that algebra is commutative, and alpha-renaming is a part 
of the definition of equivalence, then they are equivalent. If 
any of these conditions fails, or perhaps some other unusual 
conditions exist (i.e., one algebra is a modulus group), then 
the equations are not equivalent. 

Equivalence is not just something that is applicable to formal 
mathematical statements. Consider a pinball machine and a 
Sony PlayStation. How are these two things equivalent? Ob- 
viously, both are games that people play for enjoyment, so 
this classification criterion is one potential equivalence class. 
Another equivalence is that both devices have buttons, thus 
some property-based criterion imply equivalence. Another 
more subtle equivalence class is the fact that both devices 
encode the group (Z, +) because both keep score in some 
fashion. 

3.2.4 Composition 

Composition encapsulates the general notion of taking two 
or more constructs and putting them together is some way. 
Composition is a constructive operation — its result is a new 
thing that has some of the properties of its constituent pieces. 
The semantics of the specific composition operation used 
dictates the properties of the new construct. We define a 
generic semantics to which all composition operations must 
at least adhere. The symbols we use for composition are o, 
<g>, and ©. We read MoJVasM composed with N. 

Any constructive operation is composition. A father putting 
together the parts of a bicycle on Christmas Eve is perform- 
ing a type of composition; the composition of bicycle parts 
to make a bike. The cat command in UNIX systems is an- 
other example of composition; this time, of two byte streams. 

3.2.5 Realization 

As mentioned earlier, an instance I realizes a kind K. Re- 
alization is the process of stating that a specific thing is an 
instance of a specific kind. If / is an instance of a kind K, 
we say / realizes K, or / is an instance of K, or even / is 
of kind K. We use the symbol : for realization. The choice 
of symbol comes from the colon character's use in program- 
ming languages and type theory. 

Realization is the kind theory peer to typing. When one 
states "let Z be a variable of type integer", a type is be- 
ing assigned to the symbol Z. Likewise, when we state 
Z : Integer we are kinding the symbol Z as having the 
kind Integer. 

3.2.6 Interpretation 



Interpretation is the process of evaluating a construct in some 
context, translating it from one form to another. The sym- 
bols that we use for interpretation are and We read 

K ^ L as the partial interpretation kind from kind K to 

kind L by agent A in context C. Likewise, ~> is read full 
interpretation. When the agent and context are clear, we 
simply write K ~> L and read it as the full interpretation 
kind from K to L. 

An interpretation is a computable functional kind that pre- 
serves some type of structure. We define two sort of inter- 
pretation kind. 

Full interpretations are computable functions that preserve 
all structure from their domain. This means that the seman- 
tics, that is, the validity, of all related constructs is main- 
tained across interpretation. Within kind theory a full in- 
terpretation is defined as a. functor on a specific category of 
kind. 

A partial interpretation is a computable function that pre- 
serves some substructure from its domain. Partial interpre- 
tations are, categorically, forgetful functors. 

Interpretation is a transitive operation. The identity interpre- 
tation is always defined on all kinds and instances — it is the 
identity function, denoted with the term id. 

Any evaluation process is a type of interpretation. Read- 
ing this document is one kind of interpretation, evaluating 
a mathematical expression with Mathematica is another. In 
each case, data is transformed via an agent (you, the reader, 
in the former case, and the Mathematica process in the latter) 
within a specific context. 

3.2.7 Canonic ality 

Associated with every kind K is a full interpretation function 
[], read as "canonical" . Given a kind (instance) it returns the 
canonical form of that kind (instance). The canonical form 
of a canonical form is itself. 

If we have a term of the form [k] — I we call the asset I 
the canonical kind of k. Likewise, for instances, we use the 
term canonical instance. When we do not distinguish kind 
or instance, we say canonical realization or canonical asset. 

Canonicality preserves all structure of its domain and, since 
the codomain is generative (it is constructed entirely by the 
canonicality operation), then it can have no new structure. 
This means that it is possible to define a full interpretation 
between any two canonically equivalent assets, but not nec- 
essary that such interpretations exist. 

Thus, canonicality induces an equivalence relation; interpre- 
tations do not. 

3.3 Rules 

The most important rules of kind theory in the context of this 
paper are summarized in Tabled The gamma in these rules 
is an explicit context of sequents (kind theory sentences). $ 



Table 1: Relevant Rules. 

(Parent Interp*) 

r,L-» K,K ^ LY- $ r h K < P L 

rh L~~> KK ^ L = id L ,<P 
(Fully Equiv*) 

r h u = v 

(Partial Equiv*) 

T h U < V 

Th[V]D [U] 

is a list of arbitrary sentences, idi, is the identity function on 
kind L, and the asterisk denotes that the rule is reversible. 

The rule (Parent Interp*) states that, if an inheritance rela- 
tionship exists between kinds, then two interpretations must 
also exist: one that takes the parent to the child, preserving 
all structure, and a right adjoint of that map that takes the 
child to the parent. This rule essentially subsumes the re- 
lated notions of type coercion, structural type checking, and 
classification. 

The relationship between equivalence and canonicality is elu- 
cidated in the other two rules. First, two assets, that is, kinds 
or instances, are fully equivalent if and only if their canonical 
forms are identical. Second, two assets are partially equiva- 
lent if their canonical forms are structurally contained — that 
is, one of them is part of the other. 

3.4 Semantics 

Semantics are specified in an autoepistemic fashion using 
what are called truth structures. Truth structures come in 
two forms: claims and beliefs. 

Claims are stronger than beliefs. A mathematically proven 
statement that is widely accepted is a claim. This phrasing 
is used because, for example, there are theorems that have a 
preliminary proof but are not yet widely recognized as being 
true. 

A statement that is universally accepted, but not necessarily 
mathematically proven, is also a claim. Claims are not nec- 
essarily mathematical formulas. The statement "the sun will 
rise tomorrow" is considered by the vast majority of listeners 
a true and valid statement, and thus is classified as a claim 
rather than as a belief. 

Beliefs, on the other hand, range in surety from completely 
unsure to absolutely convinced. No specific metric is defined 
for the degree of conviction, the only requirement placed on 
the associated belief logic is that the belief degree form a 
partial order. 

4. SEMANTIC PROPERTIES 



Semantic properties are domain-independent documentation 
constructs with intuitive formal semantics that are mapped 
into the semantic domain of their application. We use the 
term "semantic properties" because they are properties (as 
in property-value pairs) which have formal semantics. 

Semantic properties are used as if they were normal semi- 
structured documentation. But, rather than being ignored by 
compilers and development environments as comments typ- 
ically are, they have the attention of augmented versions of 
such tools. Semantic properties embed a tremendous amount 
of concise information wherever they are used without im- 
posing the overhead inherent in the introduction of new lan- 
guages and formalisms for similar purposes. 

Our current set of semantic properties are listed in Table|2]in 
the appendix of this article, and are specified in full detail in 
Kiniry's dissertation 1 15 1. To explain their use, we will focus 
on particular enabling aspects of kind theory and provide a 
few examples of their use. 

When used in a particular language, semantic properties are 
realized using appropriate domain-specific extensions. We 
have integrated their use into the Java and Eiffel program- 
ming languages, as well as in the BON specification lan- 
guage 12 II 1251 . through a process that we call semantic em- 
bedding. 

4.1 Java 

Semantic properties are embedded in Java code using Javadoc- 
style comments. This makes for a simple, parseable syntax. 
To give some flavor to semantic embedding, we'll present a 
small example of Java code using semantic properties. Here 
is an example of such use, taken directly from one of our 
projects that uses semantic properties 1 12 1. 

/** 

* Returns a boolean indicating whether any debugging 

* facilities are turned off for a particular thread. 

* @concurrency GUARDED 

* @require (thread != null) Parameters must be valid. 

* gmodifies QUERY 

* @param thread we are checking the debugging condition 

* of this thread. 

* @return a boolean indicating whether any debugging 

* facilities are turned off for the specified thread. 

* preview kiniry - Are the isOff() methods necessary at all? 
**/ 

public synchronized boolean isOff (Thread thread) 

{ 

return ( ! isOn (thread) } ; 

} 

The method isOf f has a base specification, that of its Java 
type signature. It takes a reference to an object of type 
Thread and returns a value of base type boolean. But 
more than just its type signature is used by the Java compiler 
and runtime. Additionally, it is a public method, thus any 
client can invoke it, and it is synchronized, thus only a 
single thread of control can enter it, or any other synchro- 
nized method in the same containing class (called Debug), 
at once. This computational access control is managed by 



the Java virtual machine through the use of a monitor object 
attached to the Debug class. 

Existing tools already use these properties. Some translate 
specifications, primarily in the form of contracts, into run- 
time test code. Reto Kramer's iContract 1 18 1, the University 
of Oldenburg's Semantic Group's Jass tool, Findler and Fel- 
liason's contract soundness checking tool |10|, and Kiniry 
and Cheong's JPP 1 17 1 are four such tools. Other tools trans- 
late specifications into structured documentation. Javadoc 
and its relatives are examples of such tools. 

4.2 Kinding with Semantic Properties 

Semantic properties are used in kinding an instance (e.g., a 
method, a class, a type) in the following fashion. We do 
not have the space to fully detail the related theory and al- 
gorithm, but a detailed example should suffice is getting the 
idea across. We'll focus exclusively on kinding the above 
Java method to this end. 

The kind of this method contains much more information 
than its type. First, the kind contains everything we have al- 
ready discussed with respect to the method's signature. Ad- 
ditionally, a semantic interpretation of all of the documen- 
tation attached to the method is included. And, as a final 
element, a more complete representation of its type is also 
incorporated. 

In more detail: 

1 . All the information that is inherent in the explicit spec- 
ification of the method's signature and type are first 
composed. 

We will call this particular instance Debug. isOff. With 
respect to classification, this construct is a Java method. 
This is encoded as 

Debug.isOff : JavaMethod 

We interpret the method's signature as follows: 

Debug. isOff.ParameterSet C p Debug.isOff 
Debug. isOff.ReturnType C p Debug.isOff 

where 

Debug. isOff.ParameterSet : JavaParameterSet 
Debug. isOff.ParameterO C p Debug. isOff.ParameterSet 

Debug. isOff.ParameterO : JavaParameter 
Debug. isOff.ParameterOType C p Debug. isOff.ParameterO 
Debug. isOff.ParameterOName C p Debug. isOff.ParameterO 
Debug.isOff.ParameterOType : JavaType 
Debug. isOff.ParameterOType = java.lang. Thread 
Debug. isOff.ParameterOName : JavaIdentifier 
Debug. isOff.ParameterOName = thread 
. . . etc . . . 



Effectively, we reflectively encode all of the type and 
signature information for the method in a kind theo- 
retic context. 

The structure of the related kinds like JavaParameter 
encode the necessary structure that must be provided 
by the interpretation, a type and a name in this case. 
Thus, this part of the process is no different than the 
parsing and typing that goes along with compiling the 
method. 

2. All the supplementary information embedded via the 
use of the semantic properties and extra-type informa- 
tion is also interpreted into a kind theoretic context. 

For example, the fact that the method is declared as 
having GUARDED concurrency semantics is encoded 
with the concurrent kind: 



A SemanticComponent is a kind that contains both Provides 
and a REQUIRES kinds. Each of these enclosed kinds speci- 
fies a set of kind which the component exposes, or on which 
it depends, respectively. This two substructures are a gener- 
alization of the common exports and imports clauses of ar- 
chitecture description and component specification languages. 

If we wish to determine the semantic compatibility of two 
instances we use the following formal definition. 

Definition 1 (Semantic Compatibility). Let I and 
J be two semantic components. That is, 

r, I : SemanticComponent, J : SemanticComponent V- o 

Furthermore, I is part of the provisions of an enclosing se- 
mantic component Cp, and J is part of the requirements of 



ConcurrencySemanticsO C p Debug. isOff 
ConcurrencySemanticsO : JavaConcurrencySemantics™ enclosing semantic component C R 
ConcurrencySemanticsO = GuardedSemantics 



Th,I C P P,P 



Provides, P c p C p , 



Likewise, the method's visibility, signature concurrency 
(use of the synchronized keyword), side-effects 
(modifies), precondition, parameter and return value 
documentation, and meta-information (review) are also 
interpreted. 

3. Finally, we interpret a more complete representation of 
the method's type by taking advantage of the domain 
semantics of refinement. In this example, we attach 
stronger refinement semantics via the use of the speci- 
fied, explicit, classical contract. 

The existence of the precondition means that, after we 
interpret such, we can: (a) Check that overridden meth- 
ods properly weaken the precondition for behavioral 
subsumption. (b) Interpret such specification into run- 
time test code — here that entails just a literal insertion 
of the code snippet into the proper place(s) in a rewrit- 
ten version of the method, (c) Use this behavioral spec- 
ification as a guard in semantic composition (see be- 
low). 

The kind of this method is our formal "best-effort" at the 
specification of its semantics. Now, the rules of kind and 
instance composition come into play with respect to defining 
semantic compatibility. 



J c p R,R : Requires, R <z p C r V- o 

We say that P and R are semantically compatible if an inter- 
pretation exists that will "convert" R into the ontology ofP, 
that is if there is a R^> P in, or derivable from, the context 

r. 

I and J are semantically equivalent if I = J, of course. 

We can test for the existence of such an interpretation by 
checking to see if the canonical forms of P and R struc- 
turally contain each other. 

Theorem 1 (Semantic Compatibility Check). 

t,[r] c p [p}hR^p 

The proof of this theorem is straightforward. If [R] C p [P] 
then [P] D [R] (by definition of these operators), and thus 
by the rule (Partial Equiv*), P < R. By the definition of 
partial equivalence, when P < R, a full interpretation exists 
that takes P to R; that is, P R. This full interpretation is 
exactly the "conversion" operator that we are looking for to 
guarantee semantic compatibility. 



5. COMPONENT KIND 

Two instances (e.g, objects) are compatible if they can inter- 
operate in some fashion correctly and in a sound manner. For 
example, the two objects can perform their intended roles in 
an interactive manner and the composition of the two objects 
is as correct as the two objects when analyzed individually. 

An object O is a realization of a semantic component, that 
is, O : SemanticComponent, if it provides sufficient in- 
formation via semantic properties that a kind system can in- 
terpret its structure into a predefined kind. That is to say, 
this "parsing" step is an interpretation to some K which is a 
semantic component. 



Finally, we say that I and J can be semantically composed 
if: (a) they are semantically compatible, and (b) their com- 
position is realizable within their instance domain. 

This realization within their instance domain is the "glue" 
code on which we depend for composition. We call this con- 
struct a semantic bridge. Put another way, a semantic bridge 
is a chain of equivalences between two instances that ensures 
their contextual base equivalency. 

6. EXAMPLES 

All the examples below are defined independently of source 
object language and ignore the subtle problems of class and 



type versioning that are solved in the full system and are not 
described here. These are only illustrative, not prescriptive, 
examples. 

Finally, the "tight" coupling demonstrated below is theo- 
retically equivalent to the more dynamic coupling found in 
loosely typed systems. The same rules and implications hold 
in such an architecture. 

Some of the following examples will use the following type: 

Type DateType 

method setDate(day: Integer; 

month: Integer; 
year : Integer) ; 
method getDateO; 
EndType 

Before examining these examples, take note that if two classes 
are class or type compatible, they are obviously semantically 
compatible. 

6.1 Standard Object Semantic Compatibility 

Class Date 

method setDate(day: Integer; 

month: Integer; 

year : Integer) ; 
method getDateO; 

end; 

Class SetDate 

callmethod writeDate (day : Integer; 

month: Integer; 

year : Integer) ; 
callmethod readDate () ; 

end; 



The methods tagged with the callmethod keyword are 
part of the REQUIRES of the class; those tagged with the 
method keyword are part of the PROVIDES part. 

These classes are not type compatible since their outbound 
and inbound interfaces are of two different types (Date- 
Type and some new type; lets call it Another DateType). 

If the only difference between the methods set Date and 
writeDate is exactly their syntax, then these classes are 
semantically compatible. 

This mapping exists because both of these classes realize 
the same kind, that of DATE. We know this fact because at 
some point a developer defined this ontology by virtue of a 
claim or a belief on the classes. Such a truth structure could 
have been defined explicitly through the specification of a 
semantic property {realizes) on the classes, via manipulation 
in the development environment, or by direct input with the 
kind system. 

Now, because Date : Date, then a mapping exists from each 
of its parts (e.g., the setDate method) to each of the parts 
of the kind (the canonical setDate kind feature). 



These maps, when used in composition, define a simple re- 
naming (sort of an alpha-renaming for instances) for the classes. 
We can realize such a renaming either by directly manipu- 
lating the source text (if this is permissible in the current 
context), or by generating a simple wrapper class automati- 
cally. Thus, an adapter which maps calls from writeDate 
to setDate and from readDate to getDate will allow 
the composition of these two classes to perform correctly. 

6.2 Extended Object Semantic Compatibility 

The above example is based on a simple syntactic difference 
between two classes. Here is a more complex example. 

Consider the following two classes. 

Class ISODate 

requires: year > 1970 
method setDate (year : Integer; 

month: Integer; 
day : Integer) ; 
method getDateO: ISODate; 
EndClass 

Class SetDate 

requires: year > 
callmethod setDate (day: Integer; 

month: Integer; 
year : Integer) ; 

EndClass 



To compose an instance of SetDate with an instance of 
ISODate, we have to (a) negotiate the reordering of the 
parameters of the setDate method, and (b) check the be- 
havioral conformance of the composition. 

This reordering is just another simple form of the above 
alpha-renaming because the structural operators in kind the- 
ory (C p and D) are order-independent. The behavioral con- 
formance is verified because year > 1970 year > 0. 

Thus, we can again automatically generate the appropriate 
code to guarantee semantic compositionality. 

6.3 Ontological Semantic Compatibility 

Our final example is an example of a solution that would 
rely more strongly upon ontology-based semantic informa- 
tion encoded in kind theory. 

Consider the following classes. 

Class ISODate 

method setDate (year : Integer; 

month: Integer; 
day : Integer) ; 
method getDateO: ISODate; 
EndClass 

Class OffsetDate 

method setDate (days_since_ janl_l 97 : 
Integer) ; 

method getDateO: OffsetDate; 
EndClass 



Assume that the parameter days_since_janl_1970 was 
annotated with a reference to a kind that described days_- 
since_janl_1970 meant. The context of such a descrip- 
tion would necessarily have to have a ground — a common, 
base understanding that is universal. 

In this case, the ground element is the notion of a day. The 
relationship between the parameter days_since_janl_- 
197 and the day ground element need be established. 

This relationship might be constructed any of a number of 
correct, equivalent manners. For example, a direct inter- 
pretation from the triple year/month/day to days_since_- 
janl_1970 would suffice. 

Or perhaps a more complicated, multistage interpretation 
would be all that is available. For example, the composi- 
tion of interpretations from year to month, then month to 
day, then day to days_since_ janl.l 97 0, would provide 
enough information for the generation of a semantic bridge. 

This composition of interpretations is automatically discov- 
ered and verified using the semantic compatibility theorem 
via the rewriting logic-based component search algorithm of 
kind theory. 

7. IMPLEMENTATIONS 

The earliest implementation of this research was done by 
a student (Roman Ginis) working with the author in 1998. 
We used the Boyer-Moore theorem prover (Nqthm) to hand- 
specify the above examples (and more) and prove semantic 
compositionality. Glue code was also written by hand to see 
what steps were necessary, in typical structured languages, 
for realizing the resulting interpretations. 

We have now developed the theoretical infrastructure to com- 
pletely describe the semantic components and reason about 
their composition. We also have a realization of the theory 
in a kind system implemented in SRI's Maude logical frame- 
work |6|. Currently, the realization of renaming, reordering, 
and simple interpretations is direct: it is snippets of Java pro- 
gram code that are explicit realizations of the corresponding 
interpretation. 

Our next step is to "lift" these examples into a general con- 
text, automatically generating code in a variety of contexts, 
rather than just using pre-written, parameterized glue code. 

To this end, we have developed a distributed component- 
based web architecture called the Jiki [ 13 1 for use as a test- 
bed of semantic compositionality. The Jiki's components 
are distributed JavaBeans, and they interact via a number of 
technologies including local and remote method calls, mes- 
sage passing via HTTP and other protocols, and a tuple- 
based coordination mechanism based upon Jini's JavaSpaces. 

These components have already been specified with both the 
Extended BON |14| specification language as well as our 
semantic properties in their program code. 

Thus, our next step is to use this example, complex appli- 



cation with an existing specification as a testing ground for 
automatic generation of glue code for a variety of interface 
modalities. In the end, we would like to be able to use se- 
mantic components as a kind of "Uber-IDL", and generate 
glue code that utilizes a large variety of equivalent commu- 
nication substrates, both at compile and run-time. 

Abstracting that component-based architecture, particularly 
with a view toward component quality-of-service, has al- 
ready been finished. The result of which is what we call 
the Connector Architecture, inspired by Allen and Garlan's 
similar work jl |, and will be described in a forthcoming pa- 
per. 

8. CONCLUSION 

We have shown that, using kind theory, we can use the same 
formalism to describe software components, reason about 
their composition, and generate verifiable "glue" code for 
their composition. These specifications come in the form of 
simple domain-independent annotations to typical program 
code, and such annotations are also used for documentation 
and testing purposes. 
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APPENDIX 

A. SEMANTIC PROPERTIES SUMMARY 
Table 2: The Full Set of Semantic Properties 



Met a- Information : 


Contracts 


Versioning 


author 


ensure 


version 


bon 


generate 


deprecated 


bug 


invariant 


since 


copyright 


modifies 


Documentation 


description 


require 


design 


history 


Concurrency 


equivalent 


license 


concurrency 


example 


title 


Usage 


see 


Dependencies 


param 


Miscellaneous 


references 


return 


guard 


use 


exception 


values 


Inheritance 


Pending Work 


time-complexity 


hides 


idea 


space-complexity 


overrides 


review 




realizes 


todo 





